Why

function replicateArrayBufferError() {
  try {
    const size = 2 * 1024 * 1024 * 1024;
    const buf = new ArrayBuffer(size);
	conn.send(buf);
  } catch (e) {
    console.error(e);
  }
}

replicateArrayBufferError();
console.log('you can try catch this!!!')

tldr; a failed allocation can be try-caught by a top-level handler (e.g. in react) and river can pretend nothing went wrong and construct another message

by the time the next message comes around, its possible theres enough memory to allocate again and whoops!!! we skipped sending a message

some more context on this error: https://groups.google.com/a/chromium.org/g/blink-dev/c/pZ9kld0LehA/m/Ho-SCn8tBAAJ

What changed

• assume codecs are fallible: wrap codec in an adapter (CodecMessageAdapter) to try catch toBuffer and fromBuffer operations
• delete the session if codec fails, this should gc the message buffer for that session which should help memory pressure
• we also expose ProtocolError.MessageSendFailure so the consumer can decide to shut down the world in this case too
• modify ws connection to not throw when sending on CLOSING or CLOSED states (safe to discard as we have the sendbuffer)
• actually read the result of .send()
• added test to prevent regression
• delete unused messageFraming code (we axed UDS a while ago)

Versioning

• Breaking protocol change
• Breaking ts/js API change